1. Technical Field
The present invention relates generally to an architecture for extending the Java Security Model to allow a user or an administrator to explicitly deny permissions statically or dynamically, i.e. during runtime.
2. Description of the Related Art
Java, originally developed by Sun Microsystems, is a known software programming environment in which software programs, known as Java applets or applications, are developed, tested and maintained. Java programs have found extensive use on the World Wide Web, which is the Internet""s multimedia information retrieval system.
A capabilities-based access control model is one in which a user possesses a capability token that defines the user""s permissible access to resources. The Java 1.2 security model is capabilities-based, wherein Java classes or class instances are resource users and the class""s associated ProtectionDomain defines its capabilities with a set of Java permissions. In the Java 1.2 reference implementation, the permissions (capabilities) associated with each class are specified in one or more policy files, read in, and used to instantiate a Java Virtual Machine (JVM) Policy object and class ProtectionDomains. In that implementation, all denial of access is implicit, a result of the omission of an explicitly granted permission. There is no support for explicitly denied permissions.
Recently, Sun""s JavaSoft introduced the Java 2 development platform. The Java 2 Java runtime environment (JRE) includes a Plug-in that allows developers and users to run applets in their web browsers with different JREs. The ability to specify other JREs allows developers to call Java 2 methods within their applets. Moreover, in the Java 2 security model, administrators or users can easily grant access to a large group of related objects. For example, to grant read access to all files under c: mydirectory, the administrator specifies the following Java permission:
java.io.FilePermission xe2x80x9cc: mydirectory *xe2x80x9d,xe2x80x9creadxe2x80x9d The administrator, however, has no easy way to grant access to a large collection of related objects while denying access to one object or a small subset of them. For example, to grant read access to all the files under c: mydirectory except for c: mydirectory private.txt, the administrator would need to specify individual permissions for each of the accessible files. Clearly, this is an impractical or even impossible task in many situations. Moreover, by using multiple policy files and Java permissions containing wildcards, it is possible to inadvertently grant access to sensitive resources.
To protect those resources, there is a need to provide a Java security model with support for explicitly denied permissions that may be consulted and honored before granted permissions.
The present invention is an architecture for extending the Java security model to allow a user or administrator to deny permissions explicitly. According to the present invention, a user may define denied permissions both statically, e.g., in a policy file, and/or at runtime, e.g., via a user dialog box. In addition, the user may write dynamically defined denied permissions back to persistent policy files to enable the denied permission to exist across browser sessions.
In a preferred embodiment, the denied permission support is provided by modifying a ProtectionDomain class to include a private permissions attribute containing all permissions explicitly denied to a class, and to include several new methods: a first method to add a permission to the set of denied permissions, a second method to remove a permission from the set of denied permissions, and a third method to check for the presence of a specific permission in the set of denied permissions. In operation, an existing check permission method is modified so that at each call, the denied permissions attribute of each ProtectionDomain is checked before the granted permissions in that ProtectionDomain. If the requested permission is found in the set of denied permissions, the access is denied and a security exception is thrown. If the requested permission is not found in the denied permissions set, the existing check permission logic is followed.
In addition, the denied permissions support includes a modified policy class for reading denied permissions from a policy file. Also, subclasses of this class are modified to include a method to write any dynamic denied permissions back to policy files on disk.
The foregoing has outlined some of the more pertinent objects and features of the present invention. These objects should be construed to be merely illustrative of some of the more prominent features and applications of the invention. Many other beneficial results can be attained by applying the disclosed invention in a different manner or modifying the invention as will be described. Accordingly, other objects and a fuller understanding of the invention may be had by referring to the following Detailed Description of the Preferred Embodiment.